When a signal, for example, a multimedia-type signal, is transmitted over a single channel in a synchronous manner, the processing of a stream unit (arises few or no problems). The necessary data is received previously.
On the other hand, this is not the case in asynchronous systems that can implement several transmission channels, and/or several servers—each transmitting a part of the desired signal. This is the case, for example, in the transmission or broadcasting over an IP-type network.
In this case, we may receive a stream unit that is supposed to complete others that have not been received. For example, this could be data enrichment information of a higher hierarchical level, in which the data is encoded using hierarchical encoding (a stream can therefore correspond to a given hierarchical level.) The processing of enrichment data will therefore give a random result, generally leading to significant degradation of a recovered signal, or even the complete blocking of the decoder.
The previous art in terms of multimedia synchronisation is essentially represented by RTP-based transport protocols and by MPEG-4 (Synchronisation Layer.) In the approached used, the synchronisation mechanisms have been mainly designed for temporally synchronising audio and video streams so that they may be presented without lags. This data is conveyed using a time stamping system (a reference clock, and decoding and presentation stamps.)
With the advent of hierarchical encoding, where various time and spatial enrichment levels are used to produce a presentable frame, the inventor has noted that a new need for synchronisation arises.
Indeed, streams must be synchronised before they are decoded (and not only during their presentation.) This constraint is more complex than presentation synchronisation because the units required for decoding the unit must be identified in order to produce a correct frame. A single lag can lead an entire stream as well as all the streams that are based on it to be unusable. This is a new, not apparent, problem identified by the inventor.
A similar problem arises when a received stream unit must be decoded, or decrypted, using data (for example, a decoding key) that the terminal should have received, but has not received. Once again, the result of the decoding procedure will be, at least, inefficient, generally, harmful (in terms of recovered signal), and can lead to the blocking of the terminal. In these two cases, an undesired and troublesome process would have been performed.
Another significant problem found in broadcasting (multicast or broadcast) systems is that the same data has to be multibroadcasted to allow users connecting at any instance to receive all the stream(s) that they have selected. This specific aspect is already discussed in the request for patent EP-014600462, not yet published, in the name of the title holders of the present request for patent. According to this technique, processing is performed at transport level, which forces a processing of each stream unit, taking into account the specificities of the various transport types.
The previous art in terms of multimedia representation in broadcast and multicast scenarii is described in the specification of the “carousel MPEG-4. Nonetheless”, therefore, a certain number of functions are prohibited or become high data rate consumers. In the two delivery scenarii considered, input points to the multimedia presentation must be indicated at any time. This is translated into a repetition of data relative to the description of the scene: BIFS scene, textures.
Once the multimedia content becomes rich, this simple repetition is not unacceptable and leads to excessive downloading times. Furthermore, this specification does not allow broadcasting certain multimedia elements (short audio/video clips.)
In particular, the purpose of the invention is to overcome various inconveniences of the state of the art.